PD ROM 1

home *** CD-ROM | disk | FTP | other *** search

/ PD ROM 1 / PD ROM Volume I - Macintosh Software from BMUG (1988).iso / Electronic Messages / Delphi Digests / Delphi Vol. 2 / Delphi 2.16 < prev next >

Wrap

Text File | 1986-05-05 | 26.5 KB | 593 lines | [TEXT/ttxt]

del Message 1270693 has been deleted. Message: 1271484, 574 lines Posted: 10:46am EDT, Sun Apr 27/86, imported: 2:28pm EDT, Sun Apr 27/86 Subject: Delphi Mac Digest V2 #16 To: Peter_Johnston@UQV-MTS, MacTechnics User Group, Gavin Eadie, Abraham Vanderspek From: SHULMAN@RED.RUTGERS.EDU Delphi Mac Digest Sunday, 27 Apr 1986 Volume 2 : Issue 16 Today's Topics: 68000 Assembly Language Tools RE: 68000 Assembly Language Tools (Re: Msg 7402) RE: 68000 Assembly Language Tools (Re: Msg 7403) RE: 68000 Assembly Language Tools (Re: Msg 7402) RE: 68000 Assembly Language Tools (Re: Msg 7402) 'HOT' Tip!!! Lightspeed C TWO hard disks on Mac+ RE: Volumes 0.5 (Re: Msg 6735) Interleave/DiskBench Watch out for DataPak Software Where's Sierra Info. Systems? Re: Hyperdrive Removal request RE: Open Mac rumors cont'd (Re: Msg 7570) MDS and Lightspeed C Dollars & $ense Is Mac Really Naked? MS Word HELP!!!! ---------------------------------------------------------------------- From: GBL (7402) Subject: 68000 Assembly Language Tools Date: 17-APR 23:02 Developer's Corner I'm just finishing up a book on Mac assembly language. I thought I'd include -an appendix on "Invaluable Development Tools" or something like that. I'd like to include references to the most useful commercial and shareware utilities like Fedit, ConCode, etc. I'd like to hear comments on what you feel are the best utilities for a 68000 programmer to have at hand. Thank you. ------------------------------ From: PEABO (7403) Subject: RE: 68000 Assembly Language Tools (Re: Msg 7402) Date: 17-APR 23:40 Developer's Corner MacsBug (from Apple) or TMON (from ICOM simulations, a commercial product) are a necessity for debugging. I'll also plug a public domain product of my own, TextDiff, which is available in the Tools topic of the database here. Over the years I have come to depend of a good utility to compare successive versions of source code for what changes took place, and that's what TextDiff does. Currently in beta test, but there will a another version out in a little while with bug fixes and some nifty new features. peter ------------------------------ From: RICFORD (7406) Subject: RE: 68000 Assembly Language Tools (Re: Msg 7403) Date: 18-APR 00:43 Developer's Corner I assume you've already included ResEdit and other Apple utilities. Other... -is important for testing DA's, and I'd suggest a modem and Red Ryder as important development tools... Ric ------------------------------ From: LOFTUSBECKER (7407) Subject: RE: 68000 Assembly Language Tools (Re: Msg 7402) Date: 18-APR 07:43 Developer's Corner 1. MDSMake (Shebanow). 2. BaseTool (32-bit hex/decimal/octal/binary converter) 3. TMON (debugger). ------------------------------ From: JIMH (7411) Subject: RE: 68000 Assembly Language Tools (Re: Msg 7402) Date: 18-APR 19:07 Developer's Corner The best single tool for assembly language programming is TMON. The best tool to learn how to program in 68k ASM is MacNosy as theres no teacher like examples. jim ------------------------------ From: MACINTOUCH (7408) Subject: 'HOT' Tip!!! Date: 18-APR 17:02 Business Mac I got a great piece of info today which confirms a previous rumor that I -posted here.... dBASE III+ will be out for the Macintosh in the last quarter of this year. My source at Ashton-Tate didn't know whether the programs would be compatable between the IBM and Mac but he assumed that the data would be. Josh Wachs - MacInTouch ------------------------------ From: ASMCOR (7415) Subject: Lightspeed C Date: 19-APR 00:30 Programming All: Been playing with LightSpeed C, here are my first impressions: I have been working in Megamax for a good year now, and I've been quite happy with it, but LightSpeed is really going to spoil me... it's very easy to work in. I have a little application than I am using as a test bed for the List Manager routines, to get them all working right so I can use them. It took me -a couple of full evenings, I would guesstimate approximately 10 hours to get the thing running in Megamax. I wrote all the glue routines in assembly, and it took about 6 of those hours. Tonight, inside of three hours I was able to convert the entire LIST application from Megamax to LightSpeed, and get it running. And that *includes* re-writing all the glue routines for Lightspeed, which doesn't support inline assembly. I used the little trick posted here yesterday of declaring something like: pascal Boolean Pack0() = 0xA9E7; and using that to create the inline traps. Works great. The turnaround in Lightspeed is very fast, and the error messages are much clearer than Megamax. It also only gives you one error message at a time, so it's less confusing, and it's more accurate at flagging the line where the error actually occurs. Interestingly, the LIST application was 8930 bytes in Megamax, and 9744 in Lightspeed. About 10% larger, but that may be because it's linking in more than it has to. I think the difference would be less in a more fully-fleshed application. Still, it is significant. Jan ------------------------------ From: JIMWEINRICH (7431) Subject: TWO hard disks on Mac+ Date: 19-APR 14:34 Hardware & Peripherals Is it possible to put TWO hard disks onto a Mac+ in the following config: One SCSI disk on the SCSI port; one old-style Mac hard disk on the serial port? If so, is it also possible to put the imagewriter onto the back of the old style disk (assuming of course the proper disk)? Thanks guys! ------------------------------ From: MACLAIRD (7450) Subject: RE: Volumes 0.5 (Re: Msg 6735) Date: 20-APR 17:54 MUGS Online As an addendum to my earlier Forum message about Volumes: I reported a problem running MDS from a remote host over the AppleBus. After applying patches to allow use of System 3.1.1, the applications (Exec, Link, and PackSyms) began to work with Volumes 0.5 as well. These patches are described in the introductory notes to the "December 1985 Software Supplement Additions". See the heading "MDS (Macintosh 68000 Development System) Update"; it's on the first page. One other difference was that I ran Volumes and MDS from a 5 megabyte ProFile not shared with Lisa software. I can't see how this should make a difference. Now, PackMacs.Txt has SFGetFile as an EQU. Can anyone explain how I can write a SFGetFile macro without completely revising PackMacs.Txt? ------------------------------ From: BRECHER (7507) Subject: Interleave/DiskBench Date: 22-APR 10:19 MUGS Online Which Interleave is best? ------------------------- Recently John Bass pointed out that 1:1 interleaving is sometimes disadvantageous due to the frequency of logically-contiguous single-sector requests. He estimated that interleaving of approximately 6:1 would be optimal for handling such requests. I tested that estimate by modifying DiskBench to issue 64 single-sector requests on increasing sector addresses, in place of each prior 32KB request. I ran this "SSDiskBench", as well as the original DiskBench, on a MicahDrive at various interleaves; results were as follows (read and write results were in all cases identical or nearly so, so I show here only the read results): Interleave SSDiskBench DiskBench 1:1 6801 507 2:1 7206 812 3:1 7511 1116 4:1 7518 1523 5:1 6513 1827 6:1 2538 2233 7:1 2538 2537 8:1 2943 2943 These results clearly confirm Bass's "about 6:1" estimate for optimal handling of consecutive single-sector requests. However, Bass claimed that this is also the best system interleave -- i.e., that assuming that all requests are single-sector is appropriate. This is not to say that Bass claims that ALL requests actually are single-sector -- just that such requests are so relatively frequent that the best interleave is one which accommodates them. I gathered some statistics on the distribution of disk I/O requests by writing a hook into _Read and _Write which records the size of each request and the the sector (logical block) distance from the end of the previous request to the start of the current request. I invoked this recorder, and then performed the following activities on a 512K Mac, 128K ROMs, System 3.2b3, Finder 5.2, big TMON loaded, MicahDrive HFS volume about 9MB full, starting in Finder with the disk directory window open: Open folder; double-click MacWrite document; change document, quit with save; close folder; open folder; double-click MacPaint document; change document; quit with save; duplicate (Finder copy) 22K document; close folder; open folder; open MDS Asm; use SFGetFile to select document (go up, down, down in directory hierarchy); assemble; transfer directly to Consulair Link 1.5; Link; quit to Finder; close folder; open folder; double-click Excel worksheet document; change worksheet; quit with save; close folder. Size of disk read/write requests, 512-byte sectors: Number of sectors Number of requests Sectors transferred (%) 1 1785 1785 (49%) 2 16 32 3 16 48 4 6 24 5 23 115 6 8 48 7 3 21 8 22 176 9 4 36 10 2 20 13 1 13 14 9 126 16 1 16 17 2 34 18 2 36 23 1 23 24 1 24 25 1 25 43 1 43 44 3 152 48 1 48 49 1 49 61 1 61 63 4 252 ( 7%) 70 1 70 ( 2%) 374 (Excel PCOD resource) 1 374 (10%) ---- ---- 1916 total requests 3651 total sectors Sector distance between chronologically consecutive requests (end of request N-1 to start of request N; 0 means requests are physically contiguous): Sector distance Number of requests 0 1060 1 20 2 13 3 14 4 5 5 8 negative or 6 or more 796 ---- 1916 total requests Clearly, consecutive single-sector requests predominate. However, this is not sufficient to establish the best interleave. Consider: for each consecutive single-sector request in a series, a 1:1 drive takes about one disk revolution, and a 6:1 drive takes about one-third of a revolution. For a single 374-sector request, a 6:1 drive takes about 124 revolutions; a 1:1 drive, about 21 revolutions. Hence, in terms of relative advantage, a single 374-sector request balances a series of about 154 single-sector requests. These calculations are back-of-the envelope; the exact magnitude of the results is not the issue. The point is that a few big requests at 1:1 interleave can offset the advantage of many contiguous single-sector requests at 6:1 interleave. So, whether 1:1 or 6:1/7:1 is better from the standpoint of getting the user home quicker depends on the user's job mix. To find out what kind of activities favor interleaving or lack thereof, I wrote another _Read/_Write hook. Here, if the request started in the same cylinder in which the previous request ended, and if there were five or fewer intervening logical sectors, the relative advantage of 6:1 vs. 1:1 interleave was calculated and cumulated. And, the relative disadvantage of 6:1 in terms of sectors passing under the heads during actual data transfer was calculated and cumulated. The following is a general summary of the net winner by activity: Activity Winner All launches-- (MacWrite, MacPaint, Excel, MDS Asm, Consulair Link) 1:1 Finder copies 1:1 MDS Assembly 1:1 Consulair Link 6:1 Opening/Saving Write/Paint documents 6:1 I presume that any backup program will do multi-sector requests, and therefore would run faster with 1:1. In general, if the user does a lot of document opening/saving, then the 6:1 or so interleave is better. If he does a lot of launching/quitting (launching Finder), file copying, etc., then 1:1 is better. It should be noted, though, that with a "normal" mix of activities the perceived difference will not be great. I've been running the MicahDrive at 7:1 for a couple of days (previously 1:1); the perceived throughput is not noticeably different. I clocked a few different activities at both interleaves, and the difference was typically a few percent one way or the other. DiskBench --------- DiskBench has been aptly criticized for not being a realistic measure of normal user I/O patterns. (To which I have previously responded that it was a quick hack that was never advertised as realistic.) In light of the foregoing data, I'd like to make clear (especially to non-technical readers) that the DiskBench data transfer tests measure only performance on large multi-sector I/O requests, and that in "real life" such requests comprise only about 20% or so of the total data that goes back and forth between the Mac and the disk. Hence, DiskBench data transfer results are not necessarily representative of relative performance in real use. FOR WHAT THEY ARE WORTH, here is the last set of results I will publish: The read data transfer test consists of 100 reads of 32KB from the beginning -of the volume; the write data transfer test consists of 100 writes of 32KB to the beginning of the volume. The access time test consists of 40 repetitions of: read 512 bytes from an offset of 1MB into the volume; read 512 bytes from the beginning of the volume. Results on only one specimen should be regarded as provisional. Data transfer Access Tester ---- time ---- time Reads Writes 400K floppy drive, Apple 8756 11816 N/A S. Brecher 400K floppy drive, Apple N/A 12392 N/A G. Frascadore 400K floppy drive, Apple 8796 11629 N/A C. Nicolais 400K floppy drive, Apple N/A 12351 N/A R. Perez 800K floppy drive, SS, Apple 8758 11407 N/A S. Brecher 800K floppy drive, SS, Apple 6842 11462 N/A D. Etchells 800K floppy drive, SS, Apple 7544 11550 N/A C. Nicolais 800K floppy drive, DS, Apple 7701 10874 N/A S. Brecher 800K floppy drive, DS, Apple 7523 10913 N/A N. Fong 800K floppy drive, DS, Apple 7737 10897 N/A C. Nicolais AST 4000, AST Research 1495 1533 159 KATZ, Mousehole BBS AST 4000, AST Research 1495 1549 160 KATZ (second drive) AST 4000, AST Research 1495 1537 169 KATZ (third drive) Bernoulli Box, 5MB, Iomega 4174 24437 66 JCOM, Mousehole BBS Corvus 45MB 10080 16632 323 R. Scorer, Corvus Corvus 126MB 9822 16438 240 R. Scorer, Corvus DASCH external RAMdisk 2482 2797 N/A J. Eugenides DataFrame 20, SuperMac 1319 2233 488 J. Bean DataFrame 20, SuperMac 1344 2233 487 S. Brecher DataFrame 20, SuperMac 1319 2233 446 L. Custer Hard Disk 20, Apple 7029 7938 368 M. Chally Hard Disk 20, Apple 7074 7871 368 N. Fong Hard Disk 20, Apple 7054 7944 370 KATZ, Mousehole BBS Hard Disk 20, Apple 9714 9718 263 R. Scorer Hard Disk 20, Apple 9883 6948 368 R. Wiggins HD-20, MDIdeas 1726 3260 446 S. Brecher HD-30, MDIdeas 1749 3576 406 S. Brecher HyperDrive 10, obsolete model 1591 1616 401 S. Brecher HyperDrive 10, GCC (V2R1) 8000(?) 7982(?) 648(?) H. Conover HyperDrive 10, GCC (V2R1) 7985(?) 6892(?) 485 R. Perez HyperDrive 20, GCC (V2R1) 1703 1506 640(?) R. Ford HyperDrive 20, GCC 1704 1506 241(?) W. Luckie LoDOWN 10MB 1504 1503 321 S. Brecher LoDOWN 20MB 1503 1504 242 M. Bohlig MacBottom 10, v2.1, PCPC 4159 6897 686 M. O'Connor MacBottom 10, v2.6, PCPC 4159 6897 608 S. Aronian MacBottom 20, v2.1, PCPC 4110 6817 601 L. Becker MacBottom 20, v2.6a, PCPC 4161 6901 657 S. Fischbach MacDrive, Tecmar 6102 6704 440 L. Custer MacDrive, 10MB Fixed, Tecmar 6017 6719 401 C. Nicolais Macintosh XL, 10MB 3489 3589 370 MACLAIRD, Delphi MagNet 20, Mirror Tech. 14539 14538 322 D. Etchells MicahDrive 20 AT, Micah 508 507 488 S. Brecher MicahDrive 20 AT, Micah 508 507 527 S. Harris OverDrive 60/16MHz CPU, Levco 1102 1102 121 S. Brecher Profile, 5MB, Lisa 2/5, Apple 4107 4407 721 MACLAIRD, Delphi Quark QC-20 6476 6488 82(?) R. Thacker QuickDrive external RAMdisk 2411 2479 52 R. Bates QuickDrive external RAMdisk 2466 2535 33 J. Eugenides RamStart RAMdisk/Beck-Tech RAM 186 186 N/A G. Frascadore Warp 20, Warp Nine Engin'rng 14537 14537 321 G. Frascadore ------------------------------ From: RICFORD (7531) Subject: Watch out for DataPak Software Date: 23-APR 11:00 Business Mac One of our subscribers, Peter Fleischhacker, reports that he purchased Executive Office from DataPak software, only to find that it was obnoxiously copy-protected, so that it cannot be used on a hard disk or an 800K floppy; furthermore, it comes without any manual -- only a promise to send one when it's ready. So, Peter decided to return the product. The company would not accept it, or refund his money! A few days later, he called for technical support. This time they said that everyone was busy on a project and that it wasn't possible to help him. When asked when he _could_ get help, they replied they had no idea! Our advice: stay away from DataPak Software. Ric Ford "MacInTouch" newsletter ------------------------------ From: RICFORD (7532) Subject: Where's Sierra Info. Systems? Date: 23-APR 11:02 Business Mac Does anyone know the status of Sierra Information Systems, the company which was selling Accountant's Choice. They seem to have disappeared, at least as far as answering their phone goes. Ric Ford ------------------------------ From: RDETCHELLS (7552) Subject: Re: Hyperdrive Removal request Date: 24-APR 22:23 MUGS Online To: Michael C. Adler All I've eveer known to do is to GENTLY pry the board-guides with a small screwdriver, to release the board, allowing it to be removed in a downward direction, rather than sliding it out. --- David Etchells, DELPHI ------------------------------ From: MOUSEKETEER (7581) Subject: RE: Open Mac rumors cont'd (Re: Msg 7570) Date: 26-APR 17:20 Macintosh In Fact Dear Ric, The Expandable Mac UGLY like the PC AT?? Don't worry! I received a Kodak Instant Print of the "artist's conception" of the unit this week from a secret source at Cupertino, and really, it's kinda cute! From the front, it looks a lot like a normal Mac, but around 4 inches taller and 6 inches wider to allow room for the new larger screen. It's the side view that will take a bit of getting used to..... -------------------------*------------------------ | \ ( \ FRONT ( \ ( \ ( \ ( | / | / | | ---- ---- | | ------- ------ | \------------------------------------------------------- Yep, the new Mac is just over two feet deep! Seems the original specs were worded a bit vaguely, and required a "Bus Mac", and while WE all know they *meant* EXPANSION bus, the folks at that were thinking rather literally. It's code-named the GRUMMAC, after the company who builds the boxy buses. I'm told, also, that the little doo-dad at the top is a "pull -tab" for access to the expansion "Chassis". Hope this helps, Alf ------------------------------ From: ASMCOR (7586) Subject: MDS and Lightspeed C Date: 26-APR 20:59 Programming All- For what it's worth, i had my first experience trying to get some MDS things linked into a Lightspeed C program. I have not used MDS much, so I had a little problem figuring out how to set up the file so that the labels would be available, but once I had that right all went smoothly. The RelConv program from lightspeed worked just fine to convert the REL file into a Lightspeed library, and it linked in and worked right. So, it does work, for those who are wondering. Jan ------------------------------ From: PIZZAMAN (7591) Subject: Dollars & $ense Date: 26-APR 22:12 Bugs & Features Anyone get Dollars & $ense to work on an HD-20? I just bought a copy to do some home finance stuff, and can't believe that this very popular package is totally HD-20 incompatible. Could this be the case. Even tried Hdutil with the patch. No luck. Hasn't there been an upgrade since the origional release that wiwill let it be used with a hard disk. They've added a file called "move to top", but this isn't any better than just option control click finder. Any info available? Barry ------------------------------ From: MOUSEKETEER (7594) Subject: Is Mac Really Naked? Date: 26-APR 22:47 Telecommunicating I read an interesting book this morning, and am curious about how many here might be interested in inviting the author to an online conference. The book is "THE CULT OF INFORMATION, The Folklore of Computers and the True Art of Thinking" by Theodore Roszak (1986, Pantheon Books). While it's rather expansive (perhaps too much so?), the book challenges the computer's current status in our society, initially using as comparison the figure of the Emperor and his New Clothes, suggesting that "Unburdened of vainglorious ambition, dressed in more modest but palpable working clothes, the computer, like the emperor in the fairy tale, may yet become a reasonably valuable public servant." Also, the author suggests that by giving an undue importance to "information", which as been twisted to mean "knowledge", we may be in danger of not teaching students how to actually think. Surprisingly, the only two computer programs mentioned favorably in the book are MacPaint and MacWrite. While it would be impractical for everyone attending the conference to have read the book, it might be possible to obtain the publisher's permission to upload several selections for discussion. I will post on poll you may "vote" in to express interest (or non). Alf ------------------------------ From: MACINTOUCH (7595) Subject: MS Word HELP!!!! Date: 26-APR 22:57 Business Mac I have an interesting problem using running heads with Microsoft word: Everytime I do it, it doesn't work. (Pretty interesting, eh?) Anyway, here's the problem. I do exactly as it says in the manual and I even get the << sign in the left column but it NEVER shows up on the printout. I have it set for even and odd pages, at many different positions and NOTHING works. One weird thing does happen though: when I select and choose 'Running Head' from the menu and select the choices, after I hit <ok>, the running head in the document moves over 1.5 inches. If I have the running head right justified, it goes OFF the screen and center or left justified moves it to the right, 1.5 inches!! Any and all help would be very appreciated since I have a 30 page paper due Mon. am and it NEEDS running heads. Of course I could print it on with one of the typewriter things or whatever they're called... Thanks. josh ------------------------------ End of Delphi Mac Digest ************************ ------- Next, history, delete, reply, help, etc.? @